1. Field of the Invention
The invention relates to the field of enterprise resource planning. More specifically, the invention relates to the ability to access multiple external applications simultaneously.
2 Background of the Invention
Enterprise Resource Planning (ERP) is an industry standard term to describe the multitude of accounting oriented applications that aid in the planning and support of business process data. For many businesses ERP applications include complex information systems that support and automate business processes such as human resources, manufacturing, distribution, project management, payroll, financials, etc. Building and maintaining the interrelationships between the applications making up a ERP system is a daunting task because each application may have its own set of attributes and business rules. In addition, these applications are developed by various software vendors (e.g. SAP, PeopleSoft, Oracle, etc) that may obtain and store the data from a variety of sources (e.g. flat files, relationship databases, etc.).
In an effort to relieve some of the complexity, enterprise applications have been created that provide access to many ERP applications from a single application. For example, buying organizations may use an enterprise application to enable their corporate community of users, approvers and related departments to acquire all of their operating resources via a single, common networked infrastructure. The enterprise application channels the users to products and services from preferred suppliers while simplifying the numerous processes (e.g., approval within the organization) of acquiring operating resources. That is, the enterprise application facilitates an easy to understand presentation of each process to the user, so complexity is minimized, while still allowing the enterprise to model sophisticated process scenarios.
FIG. 1 illustrates the connectivity of two ERPs with two enterprise applications. Here, enterprise application instance 110 interfaces with ERP 102 and enterprise application instance 120 interfaces with ERP 103. The ERP 102 includes ERP database 130 and ERP database 150. The ERP 103 includes ERP database 140 and ERP database 160.
An enterprise application, may model the world using a particular set of objects. Here, ERP object 170 uses the object model from ERP 102. ERP object 180 uses the object model from ERP 103. These ERP objects relate both to real-world objects, such as suppliers and catalog items, as well as to computery items such as folders used to display work in progress to users.
The enterprise application 110 and 120 communicates with their respective ERP in their terms. This means not only importing and exporting the particular kinds of data that a given ERP uses using the object model of the ERP, but also communicating using the idiosyncratic codes of each specific ERP application. Therefore, enterprise application 110 needs to respect the semantics of each and every ERP object model. For instance, SAP may work with a particular accounting model, meaning the enterprise application communicates with it using the business rules and user Ids that the SAP understands, such as, using the SAP's user, not the enterprise application user ID.
However, a problem occurs when wanting to acquire business data not contained in a single ERP application, but spread across several ERPs of different ERP types (e.g. one SAP ERP and one Oracle ERP). Typically this occurs when a business with an existing ERP mergers with or acquires another business which has its own ERP.
For example, two businesses may have merged, each with pre-existing ERP systems of different types. (e.g. ERP 102 may use a SAP system while ERP 103 may use a PeopleSoft system). Upon merging both businesses may decide to continue to operate both ERP systems separately because one business is based in the United States and the other in France. However, at times, a user may want to access both instances simultaneously. For example, for reporting purpose. When multiple ERP instances are represented in two distinct instances a user may not immediately view both instances simultaneously in an efficient manner. To view the ERP instances simultaneously the enterprise application would somehow union the instances together or transfer the data from both instances into a data warehouse. Both these methods are inefficient and place additional overhead to the enterprise application.
Another problem with having multiple ERP systems is that different resource data may be required to work with the differing ERP instances. For example, the ERP instance for the United States may contain different resource data attributes and business rules than the ERP instance for France. Most enterprise applications map the differences between the two ERPs at runtime to keep track of which resource data is valid for which systems. However, in many cases it is not possible to map all external semantics into a single representation. Mapping dissimilar representations will result in errors to the business process.
Another possible problem when accessing multiple ERPs is that the enterprise application will have to deal with data redundancy (e.g. the possibility that the same logical entity (for instance the same employee) is represented more than once, slightly differently and with potentially conflicting data, in different systems).